Skip to content

Needs testing: Issue #10830 Surface Mode Fixes#11425

Open
breadoven wants to merge 2 commits into
iNavFlight:maintenance-9.xfrom
breadoven:abo_surface_mode_fixes
Open

Needs testing: Issue #10830 Surface Mode Fixes#11425
breadoven wants to merge 2 commits into
iNavFlight:maintenance-9.xfrom
breadoven:abo_surface_mode_fixes

Conversation

@breadoven
Copy link
Copy Markdown
Collaborator

Should close #10830.

Inhibits landing detection when Surface mode active unless AGL altitude trusted and below 10cm.

Provides OSD system message indicating Surface mode status,

Also updates OSD system message array size to take account of additional Geozone messages.

Needs testing.

@breadoven breadoven added this to the 9.1 milestone Mar 13, 2026
@sensei-hacker sensei-hacker changed the title Issue #10830 Surface Mode Fixes Needs testing: Issue #10830 Surface Mode Fixes Apr 15, 2026
@Jetrell
Copy link
Copy Markdown

Jetrell commented May 16, 2026

There was a guy on Discord today who also experienced a similar issue to this.

This was the transcript.

iNav Crash: LANDING_DETECTED mid-air at 15m due to Rangefinder out-of-range value (-1)
FC: Matek H743
GPS/Mag: Mateksys M10Q-5883
Rangefinder/OF: MicroAir MTF-02
Frame: 13" Quad | INAV 9.0.1
No GPS Fix entire flight

Incident:Quad flew above rangefinder max altitude when PosHold activated. It became stuck at 15m and refused to descend.
To force it down into rangefinder range, throttle was held at bottom (rcData=995).
Instead of descending, the quad remained frozen. 1.87s later, motors cut due to LANDING_DETECTED.
Timeline:
431605628 us: Throttle to bottom (rcData=995).
433478853 us: iNav registers LANDING_DETECTED (1.87s later).

High altitude caused MTF-02 to go out of bounds (>571cm), making surfaceRaw output -1.

Root Cause:
With PosHold enabled above limits, the sensor froze on -1, triggering a fatal landing detection loop: Frozen Altitude: Constant -1 made the estimator register 0 vertical speed, ignoring throttle input and keeping the quad stuck.
Math Trap: Since -1 is less than the landing threshold, iNav assumed the quad was on the ground.
False Landing: Zero vertical velocity combined with low throttle met all landing criteria, causing a mid-air disarm.

Quad have to be totally rebuilt, again.
This is fourth time it falls out of the air, but first time with a valid log to find the fault.

Temporarly Fix applied:
set nav_disarm_on_landing = OFF
Prevents mid-air disarm and allows barometer fallback when above rangefinder limits.

The quad also fell out of the air during RTH and PosHold earlier.
There seems to be a logical flaw in the sensor fusion (Baro/Sonar/GPS/ACC/Throttle) that allows this to happen.
A multirotor should never be able to trigger an automatic landing disarm mid-air, regardless of the throttle position.
I have two suggestions for the developers to prevent this bug:
1: Validation Check: Prevent the sonar/rangefinder from being used by the navigation system until it reads a valid, verified value within its operational bounds (not -1).
2: Descent Verification: Require the rangefinder value to actively decrease and confirm an actual descent before the landing detection algorithm can be released/triggered.

Note that he said he turned off the landing detector in this Diff, after the crash. Thinking it might be related.

There is also a slight issue with having altitude trusted below 10cm. And not just what defines TRUSTED ?
But in the case of this specific copter and many larger ones like it, that have legs/landing gear. Which positions the copters lidar sensor farther off the ground than 10cm. He said his is around 20cm above the surface while still on the ground.

DIFF - INAV_9.0.1_cli_20260516_015624 (nav_disarm_on_landing = OFF after crash).txt

LOG00042 (dropped out of air).TXT

https://www.youtube.com/watch?v=JQwIIH9OyG8&t=5s

@breadoven
Copy link
Copy Markdown
Collaborator Author

@Jetrell Yes it's the same issue as #10830. The surface logic isn't very sophisticated when the AGL altitude isn't trusted. If you switch on Althold above the range finders useable range, so it isn't trusted, it simply descends at 0.5m/s until it gets back in range and becomes trusted. When this happens the throttle stick becomes useless, high or low ... it does nothing which is pretty confusing for the pilot. Maybe the throttle stick should control the descent speed in these circumstances when AGL isn't trusted, e.g. 0.5 m/s above mid throttle with a linear increase up to say 2 m/s from throttle mid to throttle low. Would make more sense to the pilot.

Also the 0.5m/s is less than the landing detector minimum speed of 1 m/s which can cause it to trigger if the throttle is held low. Not sure why I chose 10cm as the detection cut off for this PR but it could be increased to maybe 50cm because detection is also only allowed in the PR if AGL altitude is trusted (that in itself would have prevented these crashes).

Do you not have a rangefinder equipped quad @Jetrell to test this ?

@Jetrell
Copy link
Copy Markdown

Jetrell commented May 16, 2026

Also the 0.5m/s is less than the landing detector minimum speed of 1 m/s which can cause it to trigger if the throttle is held low. Not sure why I chose 10cm as the detection cut off for this PR but it could be increased to maybe 50cm because detection is also only allowed in the PR if AGL altitude is trusted (that in itself would have prevented these crashes).

It is interesting about the 0.5m/s.. Emergency Landing descent speed is also 0.5m/s. Which I guess could also lead to a landing detector disarm if the throttle was lowered, if still in radio range.

Increasing it to 50cm shouldn't be a problem from any lidar that works well enough to be worth using..
I only have a Matek VL53L0X sensor. And they're useless in sun light. Otherwise I would have tested it by this. So no.
For the type of flying I do, I don't used them. And I can't really justify buying something like an NRA15 just for testing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants